home *** CD-ROM | disk | FTP | other *** search
/ Windows Game Programming for Dummies (2nd Edition) / WinGamProgFD.iso / pc / DirectX SDK / DXSDK / samples / Multimedia / DirectDraw / Multimon / readme.txt < prev    next >
Encoding:
Text File  |  2001-10-10  |  3.7 KB  |  75 lines
  1. //-----------------------------------------------------------------------------
  2. // 
  3. // Sample Name: Multimon Sample
  4. // 
  5. // Copyright (c) 1999-2001 Microsoft Corporation. All rights reserved.
  6. // 
  7. //-----------------------------------------------------------------------------
  8.  
  9.  
  10. Description
  11. ===========
  12.   Multimon demonstrates some of the techniques that can be used in writing
  13.   an application that takes advantage of multiple monitors.
  14.  
  15. Path
  16. ====
  17.   Source: DXSDK\Samples\Multimedia\DDraw\Multimon
  18.  
  19.   Executable: DXSDK\Samples\Multimedia\DDraw\Bin
  20.  
  21. User's Guide
  22. ============
  23.   Multimon requires no user input. Press the ESC key to quit the program.  Two
  24.   "sprites" (moving surfaces) are created.  "Sprite 1" uses video memory 
  25.   whenever possible.  "Sprite 2" always uses system memory.
  26.  
  27. Programming Notes
  28. =================
  29.   Multimon shows examples of a variety of topics:
  30.  
  31.   - To use the multimonitor APIs such as GetMonitorInfo and MonitorFromRect
  32.     on Windows 95, you can include the file multimon.h.  In addition, in one
  33.     of the C or C++ files, you need to #define COMPILE_MULTIMON_STUBS before 
  34.     including multimon.h.  This allows the multimon APIs to return reasonable
  35.     values when running on Windows 95.  If your program does not need to be
  36.     compatible with Windows 95, or if you do not use any of the multimonitor
  37.     APIs, you do not need to include multimon.h or #define 
  38.     COMPILE_MULTIMON_STUBS.
  39.  
  40.   - When enumerating DirectDraw devices, you can use either DirectDrawEnumerate
  41.     or DirectDrawEnumerateEx.  DirectDrawEnumerateEx is available on Windows 98
  42.     systems with DX5 and later, and all other systems with DX6 or later.  
  43.     Because not all systems can be assumed to have DirectDrawEnumerateEx, 
  44.     DirectDraw was set up so programmers had to use LoadLibrary and 
  45.     GetProcAddress to check for its presence.  In DX7, this restriction has 
  46.     been removed, so you can call DirectDrawEnumerateEx directly in code, but 
  47.     you should note that this will prevent your program from running on a system 
  48.     which does not have at least DX7 installed.  This sample shows how to do the 
  49.     LoadLibrary/GetProcAddress technique, and how to fall back on 
  50.     DirectDrawEnumerate if DirectDrawEnumerateEx is not available.
  51.  
  52.   - Fullscreen, multimonitor apps need to deal with focus and device windows.
  53.     The focus window receives user input messages, and the device windows are
  54.     used to cover each screen.  This program shows how to call 
  55.     SetCooperativeLevel to properly create and assign these windows.
  56.  
  57.   - Each screen gets its own DirectDraw interface, and DirectDrawSurfaces created
  58.     on one DD interface cannot be used by any other DD interface.  So creating
  59.     graphics that span multiple monitors takes some extra work.  This sample
  60.     demonstrates two techniques.  For best performance, video memory surfaces
  61.     should be used.  A separate video memory DirectDrawSurface must be created
  62.     on each screen.  For the cases where a system memory surface is required or
  63.     desired, one must still create separate DirectDrawSurfaces for each screen,
  64.     but they can be configured to point to the same surface data memory.  The 
  65.     SetSurfaceDesc API can be used to accomplish this.  Doing this has no 
  66.     performance impact, but it avoids unnecessary consumption of system memory.
  67.  
  68.   - Blt calls usually fail when they would cause data to be written outside the
  69.     borders of the destination surface.  This failure can be avoided by attaching
  70.     clipper objects to the destinations.  This sample shows how to create a 
  71.     clipper for each screen and attach it to the front and back buffers so that
  72.     the sprite surfaces can be blitted without being manually clipped by the 
  73.     application first.
  74.  
  75.